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pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 
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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Terrestrial Trunked Radio (TETRA). 
An overview of the requirements for DAWS can be found in TR 101 156. 
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Scope 



The present document specifies the service requirements for the Digital Advanced Wireless Service (DAWS) Medium 
Access Control (MAC) layer. The present document provides a conceptual architecture useful for specifying service 
requirements but is not intended to imply a particular implementation. The present document contains preliminary MAC 
protocol requirements which will be moved into the formal MAC protocol specification document (Part 5) when it is 
drafted. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 



• 



References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, subsequent revisions do apply. 

• A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with the same 
number. 

[1] TR 101 156: "Terrestrial Trunked Radio (TETRA); Technical requirements specification for 

Digital Advanced Wireless Service (DAWS)". 



[2] 


Void, 


[3] 


Void, 


[4] 


Void, 


[5] 


Void, 


[6] 


TS 1( 



TS 101 660: "Digital Advanced Wireless Service (DAWS); Physical Layer (PHY); Service 
Description". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

base station: Piece of equipment providing simultaneous, bi-directional network access to mobile stations. 

block: Fixed-length sequence of bytes from a MAC PDU. 

contention-free: Physical layer access method in which there is no possibility that two or more correctly operating 
mobile stations will transmit simultaneously in a manner which leads to mutually destructive interference between the 
transmissions. 

contention-possible: Physical layer access method in which there exists the possibility that two or more correctly 
operating mobile stations will transmit simultaneously in a manner which leads to mutually destructive interference 
between the transmissions. 

contention-reduced: Contention-possible physical layer access method designed to have reduced possibility of 
mutually destructive interference between two or more correctly operating mobile stations. 
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downlink: General term meaning "from the base station to the mobile station". 

frame: Minimum time period reserved for transmission by a single mobile station on a single frequency. 

mobile station: Piece of equipment able to create and consume data but only having network access via a base station. 

multiframe: Time period consisting of an integral number of frames between base station broadcasts specifying mobile 
station bandwidth assignments. 

protocol data unit: Set of parameters and/or data passed from peer to peer by a protocol primitive. 

protocol instance: Two protocol processes which exchange messages in order to transfer data from one protocol 
process to the other. 

protocol primitive: Request, response, or informative message sent from peer to peer. 

protocol process: Entity created to manage one end of a peer-to-peer protocol. For unidirectional data flows, a protocol 
process can be further described as either a sender process or a receiver process. 

serving cell: Physical area serviced by a base station. 

service data unit: Set of parameters and/or data passed between adjacent layers by a service primitive. 

service primitive: Request, response, or informative message sent between adjacent layers. 

sub-protocol: Portion of a protocol performing a clearly identifiable operation. 

uplink: General term meaning "from the mobile station to the base station". 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACK Acknowledged 

ARQ Automatic Repeat Request 

BE Best-Effort 

BS Base Station 

CL Controlled-Load 

DAWS Digital Advanced Wireless Service 

DL Downlink 

DQOS Data Integrity Quality Of Service 

IP Internet Protocol 

LLC Logical Link Control 

MAC Medium Access Control 

MAC_BWM MAC Bandwidth Management Service 

MAC_REG MAC Registration Service 

MAC_TPT MAC Transport Service 

MPDU MAC Protocol Data Unit 

MS Mobile Station 

MSH Mobile Station Handle 

MSI Mobile Station Identifier 

MTU Maximum Transmission Unit 

PDU Protocol Data Unit 

PHY Physical Layer 

QOS Quality Of Service 

RSVP Resource Reservation Protocol 

SAP Service Access Point 

SDU Service Data Unit 

TQOS Timing Quality Of Service 

UNACK Unacknowledged 

UL Uplink 
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Introduction 



The DAWS protocol architecture is provided in TR 101 156 [1]. The Medium Access Control (MAC) provides services 
to the Logical Link Control (LLC) and requests services from the Physical layer (PHY). The present document describes 
the services the MAC shall provide to function within a DAWS network. 

The prefix MAC will be used when a requirement applies to both the BS and MS MAC layers. The prefix BS_MAC or 
MS_MAC will be used when a requirement applies only to the BS or MS MAC layers, respectively. 

As shown in figure 1, the LLC accesses MAC services via service access points (SAPs) A, B, and C. MAC_SAP_A is 
for service primitives related to PDU transfers using unacknowledged protocols; MAC_SAP_B is for service primitives 
related to PDU transfers using acknowledged protocols; and MAC_SAP_C is for local control and status service 
primitives. 



LLC LAYER 



MAC SAP A 



MAC SAP B 



MAC SAP C 



MAC LAYER 



TRANSPORT SERVICE 
(MAC_TPT) 



B/W MANAGEMENT 

SERVICE 

(MAC_BWM) 




REGISTRATION 

SERVICE 

(MAC_REG) 



PHY SAP A 



PHY SAP B 



PHY LAYER 



Figure 1 : DAWS MAC Architecture 

The MAC accesses PHY services via service access points A and B. PHY_SAP_A is for data transfer service primitives 
and PHY_SAP_B is for control and status service primitives. 

The services provided by the MAC can be divided into three major areas: registration, bandwidth management, and 
transport. Requirements for each of these services are provided in clauses 5, 6, and 7. Service primitives and associated 
service data units are provided in clause 8. 



Registration Services 



The MAC registration service (MAC_REG) is responsible for interacting with the PHY layer to maintain the highest 
possible signal quality for the current serving cell, as well as performing adjacent cell scans when requested by 
LLC_REG. MAC_REG is also responsible for managing hand-over in sectorised cells. 

This clause will be expanded after a DAWS PHY layer is defined. 
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Bandwidth Management Services 



The MAC bandwidth management service (MAC_BWM) is responsible for allocating bandwidth over the physical 
medium for MS in full-power and power-saving modes of operation. The BS and MS share bandwidth allocation 
responsibility, and are thus jointly responsible for the timing quality of service (TQOS) delivered to flows. 

6.1 Base station bandwidth management 

BS_MAC_BWM shall allocate bandwidth on a per-MS basis, not a per-flow basis. BS_MAC_BWM shall consider the 
current state of all input queues and QOS contracts for each registered MS, and then shall dynamically allocate a portion 
of available free bandwidth to each MS. During multiframe N, BS_MAC_BWM shall prepare and send a 
PHY_configure_sysinfo_request primitive TS 101 660 [6] containing frame assignments for multiframe Nh-2 to the 
PHY layer. PHY_LNK will send the system information PDU associated with PHY_configure_sysinfo_request to all 
MS in the cell during frame of multiframe Nh-1. This MS will then have an entire multiframe to prepare for activity 
during multiframe N. 

BS_MAC_BWM shall share bandwidth allocation information with BS_MAC_TPT. BS_MAC_TPT shall issue 
PHY_transfer_request primitives to supply the BS_PHY layer with downhnk PDUs. 

6.2 IVIobile station bandwidth management 

MS_MAC_BWM shall divide the bandwidth allocation dynamically granted by BS_MAC_BWM among its 
acknowledged protocol processes. During times of increasing system congestion, MS_MAC_BWM shall decrease the 
TQOS for the best-effort protocol processes before decreasing the TQOS for the controlled-load protocol processes. 

MS_MAC_BWM shall share bandwidth allocation information with MS_MAC_TPT. MS_MAC_TPT shall issue 
PHY_transfer_request primitives to supply the MS_PHY layer with upUnk PDUs. 

6.3 Power management 

MAC-BWM shall support a power conservation strategy which allows the MS to remain in a low power consumption 
state for a considerable portion of the time. A power conserving MS shall resume normal operation before attempting an 
MPDU transfer. The QOS delivered to an MPDU from a power conserving MS shall be equivalent to that delivered to 
an MPDU from an MS operating in full-power mode, except that the downlink and uplink MPDU transfer establishment 
latency may be longer. 



Transport Services 



The MAC transport service (MAC_TPT) is responsible for the transfer of MPDUs over the physical medium. This 
clause discusses the architecture of MAC_TPT, provides requirements for the protocols in the MAC_TPT protocol 
suite, and describes MAC_TPT error handling. 

7.1 Architecture 

As shown in figures 2 and 3, MAC_TPT is composed of a suite of six separate protocols: 

• UNACK_DL: unacknowledged downlink; 

• UNACK_UL: unacknowledged uplink; 

• ACK_BE_DL: acknowledged downlink, best-effort traffic; 

• ACK_BE_UL: acknowledged uplink, best-effort traffic; 
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• ACK_CL_DL: acknowledged downlink, controUed-load traffic; 

• ACK_CL_UL: acknowledged uplink, contxolled-load traffic. 

MAC_TPT is not required to support "direct-mode" MPDU transfers, i.e. direct transfers between two or more MS 
within a single cell without intermediate handling by a BS. However, it is recommended that the design of MAC_TPT 
not preclude the addition of a direct-mode protocol at a later date. 

The MAC_TPT architecture is designed to permit easy expansion of the protocol suite (for example, the addition of 
protocols for guaranteed QOS) if necessary. 

The next two clauses describe how the six base protocols are integrated into the BS and MS MAC transport architecture. 



7.1.1 



Mobile station arcliitecture 



As shown in figure 2, MS_MAC shall create and maintain a pair of protocol processes, UNACK_DL and UNACK_UL, 
upon power-up. These processes handle the transfer of downlink and uplink PDUs using unacknowledged protocols. 

When MS_LLC registers with BS_LLC, the two LLCs co-operate to create a pair of protocol instances, ACK_BE_DL 
and ACK_BE_UL, to handle the transfer of downlink and uplink PDUs using best-effort acknowledged protocols. This 
procedure results in the creation of two MS_MAC protocol processes dedicated to best-effort traffic. 

MS_NWK is able to request the creation and deletion of protocol instances to handle controlled-load traffic. Figure 2 
shows that as MS_LLC handles these requests, MS_MAC_TPT creates and deletes protocol processes dedicated to 
downlink and uplink controlled-load traffic. 



MS MAC TRANSPORT 
SERVICE (MS_MAC_TPT) 



Unacknowledge 


1 
d 




UNACK_DL 












UNACK_UL 











Best-Effort 






ACK_BE_DL 












ACK_BE_UL 











Controded- 
Load 



X 



ACK CL DL 



ACK CL UL 



Figure 2: MAC Transport Service Architecture - IVIobile Station 

7.1 .2 Base station arcliitecture 

As shown in figure 3, BS_MAC_TPT contains one pair of protocol processes, UNACK_BE_DL and UNACK_BE_UL, 
which handle all unacknowledged traffic within the serving cell. These protocol processes are created when the BS is 
powered up. 

BS_MAC_TPT shall contain one pair of protocol processes, ACK_BE_DL and ACK_BE_UL, for each MS registered 
with the BS on the LLC level. These protocol processes manage the transfer of PDUs with best-effort QOS. 

BS_MAC_TPT shall contain multiple dynamically expanding and contracting sets of protocol processes handling 
downlink and uplink controlled-load traffic. There is one set for each registered MS, as shown in figure 3. 
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Figure 3: MAC Transport Service Architecture - Base Station 



7.2 Transport protocol suite 

This clause describes the six protocols in the MAC_TPT protocol suite in more detail. 

7.2.1 Unacknowledged downlink 

UNACK_DL shall utiUze a contention-free PHY access method available via PHY_SAP_A. A BS shall use 
UNACK_DL for system information and broadcast MPDUs. UNACK_DL PDUs may carry either a unicast or broadcast 
MSH as the destination address. 



7.2.2 Unacknowledged uplink 



UNACK_UL shall utilize a contention-possible PHY access method available via PHY_SAP_A. UNACK_UL PDUs 
may carry either a MSI or a unicast MSH as the source address. The MSI is used by an unregistered MS; the unicast 
MSH is used by a registered MS. 



7.2.3 Acknowledged protocols 



The ACK protocols shall implement a selective retransmission, ARQ strategy for MPDU transfer. The ACK protocols 
shall employ extensive error-recovery procedures to mirumize transfer failures. 

PDUs transferred by an ACK protocol may only carry a unicast MSH as the source or destination address. 

The ACK protocols shall divide each MPDU into a series of fixed length blocks. These blocks shall be in turn grouped 
into bursts, as shown in figure 4. The burst shall be the fundamental unit of information transfer over the PHY. The 
block integrity check method used by burst receivers shall be able to detect, but not necessarily correct, a bit error in a 
block. 



BURST 



BURST HEADER 
BLOCK 



BURST DATA 
BLOCKS 



MPDU DATA 
BLOCK 



MPDU 



Figure 4: Derivation of a Burst from an IVIPDU 
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The ACK protocols shall be responsible for data integrity QOS (DQOS). The DQOS supplied to an MPDU can range 
from error-free transfer (all corrupted blocks retransmitted until successfully conveyed) to partially error-free transfer 
(some corrupted blocks retransmitted; others left "as is") to open loop (no corrupted blocks retransmitted). 

The DQOS provided to the MPDUs in a flow can either be fixed at protocol instantiation or determined dynamically. 
Dynamic determination of DQOS can be useful for time-sensitive traffic. In this case, MAC_BWM (TQOS) and 
MAC_TPT (DQOS) work together to manage the QOS supplied to a flow. For example, in order to maintain a certain 
TQOS, the DQOS can be lowered to compensate for deteriorating link quality. 

The DQOS decision regarding whether or not a corrupted block in an MPDU shall be retransmitted shall originate from 
one of three sources: 

• only the MPDU sender decides; 

• only the MPDU receiver decides; 

• the MPDU sender and receiver jointly decide. 

The DQOS decision source in use shall be negotiated between sender and receiver at protocol instantiation. 

The ACK protocols shall not discard MPDUs, duplicate MPDUs, or change the transmission order of MPDUs queued 
for transmission. 

The ACK protocols shall not impose an inherent limit on the size of MPDUs. The size of the maximum transmission 
unit (MTU) on a link shall be negotiated between sender and receiver at protocol instantiation. 

Any ACK protocol using a PHY access method with contention shall use an exponential back-off algorithm for 
retransmission in case of collision. 

The ACK protocols shall efficiently transfer a stream of MPDUs, such as is typically found in bursty best-effort MPDU 
traffic and controlled-load flows. This shall include creating bursts which are composed of blocks from two or more 
consecutive MPDUs destined for the same receiver. 

The ACK protocols shall include sender flow control capability, by which the MPDU sender can inform 
BS_MAC_BWM of near-term bandwidth requirements. BS_MAC_BWM shall utilize sender flow control information 
in addition to any existing controlled-load contracts when performing bandwidth allocations among registered MS. For 
downlink transfers, sender flow control information shall be passed via an internal interface between BS_MAC_TPT 
and BS_MAC_BWM. For uplink transfers, sender flow control information shall be signalled between MS_MAC_TPT 
and BS_MAC_BWM. Sender flow control may result in MPDU transfer suspension for a brief period. 

The ACK protocols shall include receiver flow control capability, by which the MPDU receiver can inform 
BS_MAC_BWM of near-term reception capability. BS_MAC_BWM shall utilize receiver flow control information in 
addition to any existing controlled-load contracts when performing bandwidth allocations among registered MS. For 
downlink transfers, receiver flow control information shall be signalled between MS_MAC_TPT and BS_MAC_BWM. 
For uplink transfers, receiver flow control information shall be passed via an internal interface between BS_MAC_TPT 
and BS_MAC_BWM. Receiver flow control may result in MPDU transfer suspension for a brief period. 

7.2.3.1 Acknowledged Downlink, Best-effort QOS 

ACK_BE_DL shall perform a physical layer bandwidth reservation and release for each individual MPDU transferred. 
If there are multiple MPDUs queued for transfer, ACK_BE_DL may delay bandwidth release until all queued MPDUs 
are transferred. 

The ACK_BE_DL bandwidth reservation sub-protocol shall utilize a contention-free PHY access method. The MPDU 
transfer and bandwidth release sub-protocols shall also utilize a contention-free PHY access method. 
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7.2.3.2 Acknowledged Uplink, Best-effort QOS 

ACK_BE_UL shall perform a physical layer bandwidth reservation and release for each individual MPDU transferred. 
If there are multiple MPDUs queued for transfer, ACK_BE_UL may delay bandwidth release until all queued MPDUs 
are transferred. 

The ACK_BE_UL bandwidth reservation sub-protocol shall utilize a contention-possible PHY access method. The 
MPDU transfer and bandwidth release sub-protocols shall utilize a contention-free PHY access method. 

7.2.3.3 Acknowledged Downlink, Controlled-load QOS 

ACK_CL_DL shall perform a physical layer bandwidth reservation upon instantiation and a physical layer bandwidth 
release upon termination. 

The ACK_CL_DL bandwidth reservation sub-protocol shall utilize a contention-free PHY access method. The MPDU 
transfer and bandwidth release sub-protocols shall also utilize a contention-free PHY access method. 

7.2.3.4 Acknowledged Uplink, Controlled-load QOS 

ACK_CL_UL shall perform a physical layer bandwidth reservation upon instantiation and a physical layer bandwidth 
release upon termination. 

The ACK_CL_UL bandwidth reservation sub-protocol shall utilize a contention-reduced PHY access method. The 
MPDU transfer and bandwidth release sub-protocols shall utilize a contention-free PHY access method. 

A contention-reduced PHY access method for bandwidth reservation is required so that the uplink transfer establishment 
latency supplied to controlled-load flows does not experience significant degradation during system congestion. Further 
research is required to determine whether a contention-free PHY access method for uplink bandwidth reservation is 
feasible for controlled-load flows. 

7.3 Transport failure handling 

This clause describes how MAC_TPT shall respond to transport protocol failures. For this clause, the term "MPDU 
source" means a source either internal to the MAC or an SPDU passed via a MAC service access point. 

7.3.1 Unacknowledged downlink failure 

The failure of UNACK_DL to transfer an MPDU shall not be signalled to the MPDU source. MPDU transfer will 
continue with the next queued MPDU, if any. 

7.3.2 Unacknowledged uplink failure 

The failure of UNACK_UL to transfer an MPDU shall not be signalled to the MPDU source. MPDU transfer will 
continue with the next queued MPDU, if any. 

7.3.3 Acknowledged failure 

The failure of an ACK protocol to successfully transfer an MPDU shall be interpreted as a localized link failure between 
a BS and an MS. All MPDUs queued for the failed protocol instance shall be discarded, an error shall be returned to the 
MPDU source, and the instance shall be deleted. All other ACK protocol instances shall continue to operate normally. 
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8 

8.1 

8.1.1 



Service Primitives 



Primitive Definitions 
MAC_unack_transfer_request 



Table 1 



MAC_unack transfer_request 


Usage 


BS and MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


A 


Multiple Outstanding 


No 


SDU Parameters 


LPDU 



This primitive is used by the LLC layer to pass a LPDU to the MAC layer for transfer to one or more peer MAC SAP 
As. If this primitive is issued by the BS, the downlink unacknowledged protocol will handle the transfer. If it is issued 
by the MS, the uplink unacknowledged protocol will handle the transfer. 



8.1.2 



MAC unack transfer confirm 



Table 2 



MAC_unack_transfer_confirm 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


A 


SDU Parameters 


unack_transfer_receipt_ack 



This primitive acknowledges the receipt of the LPDU associated with a MAC_unack_transfer_request. It does not 
indicate that the LPDU has been transferred to one or more peer SAPs. 



8.1.3 



MAC_unack_transferJndication 

Table 3 



MAC_unack_transferJndication 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


A 


SDU Parameters 


LPDU 



This primitive is used by the MAC to pass a received LPDU to the LLC layer. 



ETSI 



15 



TS101 659 V1. 1.1 (1999-04) 



8.1.4 



MAC_ack_transfer_request 



Table 4 



MAC_ack_transfer_request 


Usage 


BS and MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


B 


Multiple Outstanding 


No 


SDU Parameters 


protocolJnstanceJD 




LPDU 



This primitive is used by the LLC layer to pass a LPDU to the MAC layer for transfer to a peer MAC SAP B. The 
protocol instance ID parameter indicates which protocol process should handle the transfer. 



8.1.5 MAC ack transfer confirm 



Table 5 



MAC_ack_transfer confirm 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


B 


SDU Parameters 


ack_transfer_receipt_ack 



This primitive acknowledges the receipt of the LPDU associated with a MAC_ack_transfer_request. It does not indicate 
that the LPDU has been transferred to one or more peer SAPs. 



8.1.6 



MAC_ack_transferJndication 

Table 6 



IViAC_ack_transfer indication 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


B 


SDU Parameters 


protocolJnstanceJD 




ackjransfer_result 




LPDU 



This primitive passes a received LPDU to the LLC layer. The protocol instance ID of the protocol instance which 
performed the transfer is provided. 
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8.1 .7 MAC_create_protocol_request 



Table 7 



MAC_create_protocoLrequest 


Usage 


BS and MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


C 


Multiple Outstanding 


No 


SDU Parameters 


protocolJnstanceJD 




MS_handle 




protocol_type 




protocol_parameters 



This primitive requests the allocation of resources for a new acknowledged protocol instance. 

8.1 .8 MAC_create_protocol_confirm 

Table 8 



MAC_create_protocol_confirm 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


C 


SDU Parameters 


create_protocol_result 



This primitive confirms the creation of the requested protocol. 



8.1 .9 MAC_delete_protocol_request 



Table 9 



MAC_delete_protocoLrequest 


Usage 


BS and MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


C 


Multiple Outstanding 


Yes 


SDU Parameters 


protocol_instance_ ID 



This primitive requests the deletion of a protocol instance. Any PDUs queued for transmission will be discarded. 
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8.1 .1 MAC_delete_protocol_confirm 



Table 10 



MAC_delete_protocol_confirm 


Usage 


BS and MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


C 


SDU Parameters 


protocol_instance_ ID 




delete_protcol_result 



This primitive confirms the deletion of a protocol instance. 

8.1.11 MAC_hunt_request 



Table 11 



MAC_hunt_request 


Usage 


MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


C 


IVIultiple Outstanding 


No 


SDU Parameters 


— 



This primitive tells the MAC to perform signal strength and signal quality measurements on the serving cell (if any) and 
all adjacent cells. 

8.1.12 MAC_hunt_confirm 

Table 12 



MAC_hunt_confirm 


Usage 


MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


C 


SDU Parameters 


hunt_result 



This primitive returns cell measurement results to MS_LLC. 

8.1.13 MAC_service_request 



Table 13 



MAC_service_request 


Usage 


MS 


Source 


LLC Layer 


Destination 


MAC Layer 


Service Access Point 


C 


Multiple Outstanding 


No 


SDU Parameters 


base_station_ID 



This primitive tells the MAC to camp on the BS specified by base_station_ID. 
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8.1.14 MAC service confirm 



Table 14 



MAC_service_confirm 


Usage 


MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


C 


SDU Parameters 


service_result 



This primitive confirms a service request. 

8.1.15 MAC service indication 



Table 15 



IVIAC_service_indication 


Usage 


MS 


Source 


MAC Layer 


Destination 


LLC Layer 


Service Access Point 


C 


SDU Parameters 


service_status 



This primitive is used by the MAC to asynchronously provide the LLC with the latest service status. 



8.2 



Parameter Definitions 



8.2.1 base_station_ID 

This parameter specifies a particular DAWS BS. 
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8.2.2 ack_transfer_receipt_ack 



Table 16 



ack_transfer_receipt_ack 



success: receipt acknowledged 



failure: transfer request already pending 



8.2.3 ack transfer result 



Table 17 



ack transfer result 





success: transfer OK 


1 


failure: transfer failed or aborted 



8.2.4 configure_scheduling_result 



Table 18 



configure_scheduling_result 



success: scheduler configured as requested 



failure: specified protocol instance does not exist 



8.2.5 create_protocol_result 



Table 19 



create_protocoLresult 



success: requested protocol created 



failure: create protocol request already pending 



failure: requested resources unavailable 



8.2.6 delete_protocol_result 



Table 20 



delete_protocol_result 



success: requested protocol deleted 



failure: protocol instance does not exist 



8.2.7 hunt_result 

This parameter consists of a list of available cells with associated signal strength and signal quality measurements. The 
parameter will be defined when the DAWS PHY is defined. 

8.2.8 LPDU 

Definition of this parameter is beyond the scope of the present document. Most often, it will consist of a LLC layer 
header and an IP datagram. 

8.2.9 MS_hanclle 

This parameter is an identifier used to identify a particular MS while it is registered with a BS. 
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8.2.10 new_scheduling_state 



Table 21 



new_scheduling_state 





scheduling disabled 


1 


scheduling enabled 



8.2.11 new service state 



Table 22 



new_service_state 





service now unavailable 


1 


service now available (new subnet) 



8.2.12 protocol_instance_ ID 

This parameter uniquely identifies a protocol instance. 

8.2.13 protocol_parameters 

This parameter contains information required by the MAC to properly manage the protocol instance. It will be further 
refined in a future version of the present document. 



8.2.14 protocol_ type 



Table 23 



protocoLtype 





Best-effort downlink 


1 


Best-effort uplink 


2 


Controlled-load downlink 


3 


Controlled-load uplink 



8.2.15 queue_empty_result 



Table 24 



q ueue_em pty_resu It 



success: input queue of protocol instance is empty 



failure: protocol instance does not exist 



8.2.16 service result 



Table 25 



service result 



success: requested service now available 



failure: could not complete request 



8.2.17 service_status 

This parameter indicates whether service is currently provided, and if so, the base_station_ID, current signal strength, 
and quality of the service. This parameter will be further defined after the DAWS PHY is defined. 
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8.2.18 unack_ transfer_receipt_ack 

Table 26 



unack_transfer_receipt_ack 



success: receipt acknowledged 



failure: transfer request already pending 
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